Pyrra 实战指南：Kubernetes 原生的 SLO 监控工具原创

SRE 工具实战 · 深度指南 | 约 8000 字 | 预计阅读 22 分钟 | Pyrra v0.7+

上一篇讲了 Sloth——通过 CLI 把 YAML 转成 Prometheus 规则。Sloth 的定位是声明式规则生成器，生成完就结束了，不负责后续的查看和管理。

Pyrra 不一样。它不仅是规则生成器，更是一个完整的 SLO 运营平台——CRD 定义 SLO、Operator 自动同步规则、Web UI 实时查看错误预算和燃烧率、Grafana Dashboard 开箱即用。如果你在 Kubernetes 环境下做 SLO，Pyrra 可能比 Sloth 更适合你。

本文深入讲透 Pyrra 的架构、四种 SLI 类型、生成规则解析、Web UI 和高级用法。

1 Pyrra 的定位：不只是规则生成器

先理解 Pyrra 和 Sloth 的核心差异——这不是功能多少的问题，而是设计哲学的差异。

Sloth 的设计哲学：CLI 工具，YAML → 规则文件 → 结束。Sloth 不关心规则加载后的状态，不提供 UI 查看错误预算，不帮你管理 SLO 生命周期。它是无状态的命令行工具。

Pyrra 的设计哲学：运营平台，CRD 定义 SLO → Operator 持续同步 → Web UI 实时查看 → Grafana Dashboard 开箱即用。它是有状态的长运行服务，不仅生成规则，还帮你理解和运营 SLO。

具体来说，Pyrra 额外提供三件 Sloth 做不到的事情：

能力	Sloth	Pyrra
规则生成	✅ CLI 生成 YAML	✅ Operator 自动同步
SLO 列表页	❌ 无	✅ 按 error budget 排序，一键筛选
SLO 详情页	❌ 无	✅ 可用性、错误预算、RED 指标、燃烧率告警一览
Grafana Dashboard	需手动导入	✅ `--generic-rules` 自动生成
非 K8s 场景	✅ 支持	✅ filesystem 模式
实时错误预算查询	❌ 需自己在 Grafana 写 PromQL	✅ Web UI 直接展示

🔑 一句话总结：Sloth 是"给我 YAML，我给你规则"的工具；Pyrra 是"给我 SLO 定义，我帮你生成规则、看数据、管告警"的平台。如果你只需要生成规则且不在 K8s 上，Sloth 更轻量；如果你在 K8s 上且想要可视化运营，Pyrra 更完整。

2 架构概览：三组件设计

Pyrra 由三个组件组成，全部打包在一个二进制文件中：

Backend 层（规则生成链路）： SLO CRD → Backend (Operator/filesystem) → PrometheusRule → Prometheus 加载

API/UI 层（查询展示链路）： API ← Backend（读取 SLO）→ Web UI（展示错误预算、燃烧率等）

三个组件的职责：

组件	启动参数	职责
Backend / Operator	`kubernetes` 或 `filesystem`	监视 SLO 对象（K8s CRD 或文件），生成 PrometheusRule 或规则文件
API	`api`	从 Backend 读取 SLO 列表，查询 Prometheus 获取实时数据，通过 HTTP API 暴露给 UI
UI	内嵌在 API 中	React 前端，展示 SLO 列表、错误预算、燃烧率、RED 指标

两种运行模式

Kubernetes 模式：两个 Deployment（API + Operator）。Operator 监视 ServiceLevelObjective CRD，自动创建 PrometheusRule 对象，由 Prometheus Operator 拾取。如果没装 Prometheus Operator，可用 --config-map-mode=true 把规则写入 ConfigMap。

Filesystem 模式：两个进程（API + filesystem reconciler）。从文件系统读取 SLO YAML，生成规则文件写入磁盘，由 Prometheus rule_files 加载。适合非 K8s 环境或本地开发。

3 安装部署

方式一：Kubernetes + Helm（推荐）

shell

# 添加 Helm 仓库
helm repo add pyrra https://pyrra-dev.github.io/helm-charts/
helm repo update

# 安装 Pyrra
helm install pyrra pyrra/pyrra \
  --namespace monitoring \
  --create-namespace \
  --set prometheus.url=http://prometheus-server.monitoring.svc:9090 \
  --set prometheus.externalUrl=http://prometheus.example.com

# 验证
kubectl get pods -n monitoring -l app.kubernetes.io/name=pyrra

方式二：Kubernetes + 原生 YAML

shell

# 部署 CRD 和 Pyrra 组件
kubectl apply --server-side -f https://github.com/pyrra-dev/pyrra/releases/latest/download/crds.yaml
kubectl apply --server-side -f https://github.com/pyrra-dev/pyrra/releases/latest/download/pyrra.yaml

# 带 Validating Webhook（需要 cert-manager）
kubectl apply --server-side -f https://github.com/pyrra-dev/pyrra/releases/latest/download/pyrra-webhook.yaml

💡 Validating Webhook 的价值：带 Webhook 的部署方式会在 kubectl apply SLO 对象时实时校验配置——Target 范围、窗口格式、PromQL 语法、SLI 类型互斥性等。配置错误会在 apply 阶段直接拒绝，而不是等到 Operator 处理时才发现。强烈建议在集群中部署 Webhook。

方式三：Docker / 文件系统模式

shell

# 拉取镜像
docker pull ghcr.io/pyrra-dev/pyrra:v0.7.0

# 启动 API（连接 Prometheus，提供 Web UI）
docker run -d --name pyrra-api -p 9099:9099 \
  -v $(pwd)/slos:/slos \
  ghcr.io/pyrra-dev/pyrra:v0.7.0 \
  api --api-url=http://pyrra-filesystem:9444 \
  --prometheus-url=http://prometheus:9090

# 启动 filesystem reconciler（读取 SLO 文件，生成规则）
docker run -d --name pyrra-fs \
  -v $(pwd)/slos:/slos \
  -v $(pwd)/rules:/rules \
  ghcr.io/pyrra-dev/pyrra:v0.7.0 \
  filesystem --fs.path=/slos --fs.rules=/rules

4 CRD 配置详解

Pyrra 使用 ServiceLevelObjective CRD 定义 SLO。这是与 Sloth 最大的配置差异——Pyrra 的配置是 Kubernetes 原生的，可以用 kubectl 管理。

基础示例：HTTP API 可用性

yaml

# slo-api-availability.yaml
apiVersion: pyrra.dev/v1alpha1
kind: ServiceLevelObjective
metadata:
  name: api-availability
  namespace: monitoring
  labels:
    prometheus: k8s
    role: alert-rules
    pyrra.dev/team: payments     # 以 pyrra.dev/ 开头的标签会传播到 Prometheus
spec:
  target: "99.9"                   # SLO 目标 99.9%（字符串类型！）
  window: 2w                        # 2 周评估窗口
  description: "HTTP API 非 5xx 响应率"
  indicator:
    ratio:
      errors:
        metric: http_requests_total{job="api", code=~"5.."}
      total:
        metric: http_requests_total{job="api"}
      grouping:
        - route                     # 按 route 标签分组，为每个路由生成独立 SLO

Spec 字段详解

字段	类型	必填	说明
`target`	string	是	SLO 目标值，0-100 的字符串（如 `"99.9"`）。用字符串是因为 Kubebuilder 不支持 CRD 中的 float 类型
`window`	string	是	评估窗口，如 `1d`、`2w`、`28d`
`description`	string	否	SLO 描述，会显示在 Web UI 中
`indicator`	object	是	SLI 指标定义，四种类型互斥
`alerting`	object	否	告警配置，见下文
`partial_response_strategy`	string	否	Thanos 部分响应策略：`abort` 或 `warn`
`performanceOverAccuracy`	bool	否	性能优先于准确性（用更快但不精确的查询）
`ruleOutput`	object	否	自定义生成 PrometheusRule 的标签

⚠️ target 是字符串，不是数字 Pyrra 的 target 字段是字符串类型——"99.9" 而不是 99.9。这是 Kubernetes CRD 的限制：Kubebuilder 不支持 float 类型，所以用字符串传入后内部转为 float64。如果你写 target: 99.9（不加引号），kubectl 可能会报错或被自动转成字符串。始终用引号包裹。

5 四种 SLI 类型

Pyrra 支持四种 SLI 指标类型，比 Sloth 的两种（events + raw）更丰富。每种类型解决不同的监控场景。

类型一：ratio（错误率，最常用）

比率型 SLI，提供 errors（错误事件）和 total（总事件），Pyrra 自动计算 errors / total。与 Sloth 的 events 类型几乎等价。

yaml

indicator:
  ratio:
    errors:
      metric: http_requests_total{job="api", code=~"5.."}
    total:
      metric: http_requests_total{job="api"}
    grouping:
      - route

适用场景：HTTP API 可用性、gRPC 错误率、消息消费失败率。这是最推荐的 SLI 类型——直接符合 good_events / total_events 的 SRE 工程化定义。

类型二：latency（延迟，直方图）

延迟型 SLI，提供 success（成功请求，即快于阈值的请求）和 total（总请求）。关键区别：success 必须包含 le 标签匹配器（histogram bucket），total 应以 _count 结尾。

yaml

indicator:
  latency:
    success:
      # 必须含 le 标签——用 histogram bucket 的 le="0.5" 表示 ≤500ms 的请求
      metric: http_request_duration_seconds_bucket{
        job="api", le="0.5"
      }
    total:
      # 通常以 _count 结尾
      metric: http_request_duration_seconds_count{job="api"}
    grouping:
      - route

适用场景：请求延迟 SLO（如"99% 的请求在 500ms 内完成"）。比 Sloth 手写 events 类型的延迟 SLI 更简洁——Pyrra 直接理解 histogram bucket 语义，不需要你手动算 _count - _bucket。

💡 latency 类型 vs Sloth 的延迟实现 在 Sloth 中实现延迟 SLO 需要用 events 类型，手动写 _count - _bucket(le=0.5) 得到"慢请求数"作为 error_query。Pyrra 的 latency 类型直接提供 success 和 total，语义更清晰：success 是"快请求"，total 是"所有请求"，success / total 就是"快请求占比"。

类型三：latencyNative（原生直方图延迟）

使用 Prometheus 原生直方图（Native Histograms）的延迟 SLI。不需要指定 success bucket，只需提供 total 指标和延迟阈值。

yaml

indicator:
  latencyNative:
    total:
      metric: http_request_duration_seconds{job="api"}
    latency: "500ms"     # 请求应快于 500ms
    grouping:
      - route

适用场景：如果你的 Prometheus 开启了 Native Histograms（实验特性），latencyNative 比传统 latency 类型更高效——不需要预定义 bucket 边界，查询时动态计算。

类型四：bool_gauge（布尔指标）

布尔型 SLI，用于衡量某个 gauge 指标是否"成功"（值为 1）。适合非请求/事件类的健康检查场景。

yaml

indicator:
  bool_gauge:
    metric: kube_node_condition{condition="Ready", status="true"}
    grouping:
      - node

适用场景：节点就绪率、证书有效期检查、DB 连接池健康度。这类 SLO 不是"请求成功率"，而是"某个状态在窗口内为 true 的时间占比"。

🔑 四种类型的选择逻辑有错误事件和总事件？ → ratio 有延迟直方图？ → latency 用了 Native Histograms？ → latencyNative 监控的是状态而非请求？ → bool_gauge

grouping：一条配置覆盖多个 SLO

grouping 是 Pyrra 的杀手特性——一条 SLO 配置可以自动展开为多个独立 SLO。

yaml

# 不用 grouping：所有路由共享一个 SLO
indicator:
  ratio:
    errors:
      metric: http_requests_total{code=~"5.."}
    total:
      metric: http_requests_total

# 用 grouping：每个 route 自动生成独立 SLO
indicator:
  ratio:
    errors:
      metric: http_requests_total{code=~"5.."}
    total:
      metric: http_requests_total
    grouping:
      - route  # /api/pay → 独立 SLO，/api/users → 独立 SLO...

Web UI 会自动展示每个分组的独立 SLO 状态，你可以在列表页按 route 筛选。这比 Sloth 为每个路由单独写一个 SLO 配置高效得多。

6 理解 Pyrra 生成的规则

和 Sloth 一样，Pyrra 也生成 recording rules 和 alert rules。但命名方式和结构有差异。

Recording Rules

以 http_requests_total 指标为例，Pyrra 生成以下 recording rules：

http_requests:increase2w — 2 周窗口的总请求数增长量
http_requests:burnrate3m — 3 分钟燃烧率
http_requests:burnrate15m — 15 分钟燃烧率
http_requests:burnrate30m — 30 分钟燃烧率
http_requests:burnrate1h — 1 小时燃烧率
http_requests:burnrate3h — 3 小时燃烧率
http_requests:burnrate12h — 12 小时燃烧率
http_requests:burnrate2d — 2 天燃烧率

命名规则：{指标名简写}:{操作}{窗口}。指标名 http_requests_total 被简化为 http_requests，去掉 _total / _count / _bucket 后缀。

🔑 与 Sloth 命名的差异 Sloth 使用统一前缀 slo:sli_error:ratio_rate5m，所有 SLO 共享同一套命名。Pyrra 使用原始指标名作为前缀，如 http_requests:burnrate3m。Sloth 的命名更适合跨服务统一查询，Pyrra 的命名更直观——看规则名就知道来自哪个指标。

Alert Rules：四级燃烧率告警

Pyrra 生成 4 条 multi-window burn rate 告警，比 Sloth 的 2 条（Page + Ticket）更精细：

级别	长窗口	短窗口	燃烧率	含义	默认 severity
Critical（快烧）	1h	5m	×14.4	2% 预算 1h 烧光	critical
Warning（中烧）	6h	30m	×6	5% 预算 6h 烧光	warning
Slow Burn（慢烧）	1d	2h	×3	10% 预算 1d 烧光	none
Long Term（长期）	3d	6h	×1	10% 预算 3d 烧光	none

💡 四级告警 vs Sloth 两级告警 Sloth 只生成 Page 和 Ticket 两级。Pyrra 的 4 级中，前 2 级对应 Sloth 的 Page（快烧），后 2 级对应 Ticket（慢烧）。多一层分级让你在 Alertmanager 里可以配置更精细的路由策略——比如 Critical 直接电话，Warning 发企业微信，Slow Burn 创建工单。

Short / Long 规则分离

Pyrra 会把生成的 PrometheusRule 分成两个对象：

对象	名称	内容	目的
Short Rules	`{slo-name}-short`	5m/15m/30m/1h 窗口的 burn rate + alert	短期告警，需要快速刷新
Long Rules	`{slo-name}-long`	3h/12h/2d 窗口的 burn rate + increase	长期趋势，刷新频率低

这样设计是因为 Prometheus 的 evaluation_interval 对短窗口和长窗口的需求不同——短窗口需要更高频的评估（如 30s），长窗口可以低频评估（如 5m），分开后可以分别配置 eval_interval 来优化性能。

缺失指标告警

除了燃烧率告警，Pyrra 还会生成一条缺失指标告警（默认开启）：

promql

# 当 SLO 的核心指标缺失时告警
absent(http_requests_total{job="api"})

这条告警帮你发现"指标采集断了"的问题——如果 Prometheus 抓不到指标，所有 SLO 计算都会失真，但燃烧率告警不会触发（因为 burn rate 趋近 0）。缺失指标告警是最后一道防线。

7 告警配置

自定义告警名称和 Severity

默认告警名称是 ErrorBudgetBurn，默认 severity 分为 critical、warning、none、none。你可以自定义：

yaml

spec:
  target: "99.9"
  window: 2w
  indicator:
    ratio:
      errors:
        metric: http_requests_total{code=~"5.."}
      total:
        metric: http_requests_total
  alerting:
    # 自定义告警名称
    name: "APIErrorBudgetBurn"
    # 自定义各级别 severity
    severities:
      fastBurn: "page"          # ×14.4 燃烧率 → 电话/短信
      mediumBurn: "ticket"      # ×6 燃烧率 → 工单
      slowBurn: "info"          # ×3 燃烧率 → 企微通知
      longTermBurn: "info"      # ×1 燃烧率 → 企微通知
      absent: "warning"         # 指标缺失 → 告警

禁用告警

yaml

spec:
  target: "99.9"
  window: 2w
  indicator:
    ratio: { ... }
  alerting:
    # 禁用所有燃烧率告警（只保留 recording rules）
    burnrates: false
    # 禁用缺失指标告警
    absent: false

Alertmanager 路由

yaml

route:
  group_by: ["slo", "team"]
  group_wait: 10s
  routes:
    # 快烧 → 电话
    - matchers:
        - severity = "page"
      receiver: oncall-phone
      group_wait: 0s
      repeat_interval: 30m

    # 中烧 → 工单
    - matchers:
        - severity = "ticket"
      receiver: ticket-system
      group_wait: 5m

    # 慢烧 / 长期 → 企微
    - matchers:
        - severity = "info"
      receiver: wechat-notify
      group_wait: 30m

    # 指标缺失 → 告警
    - matchers:
        - severity = "warning"
        - slo = "SLOMetricAbsent"
      receiver: oncall-phone

8 实战：多服务多 SLI 配置

支付服务：可用性 + 延迟 + DB 健康

yaml

# payment-api 三组 SLI
---
apiVersion: pyrra.dev/v1alpha1
kind: ServiceLevelObjective
metadata:
  name: payment-availability
  namespace: monitoring
  labels:
    pyrra.dev/team: payments
    pyrra.dev/service: payment-api
spec:
  target: "99.9"
  window: 2w
  description: "支付 API 非 5xx 响应率"
  indicator:
    ratio:
      errors:
        metric: http_requests_total{job="payment-api", code=~"5.."}
      total:
        metric: http_requests_total{job="payment-api"}
      grouping:
        - route
  alerting:
    severities:
      fastBurn: "page"
      mediumBurn: "ticket"

---
apiVersion: pyrra.dev/v1alpha1
kind: ServiceLevelObjective
metadata:
  name: payment-latency
  namespace: monitoring
  labels:
    pyrra.dev/team: payments
    pyrra.dev/service: payment-api
spec:
  target: "99"
  window: 2w
  description: "支付请求 500ms 内完成率"
  indicator:
    latency:
      success:
        metric: http_request_duration_seconds_bucket{
          job="payment-api", le="0.5"
        }
      total:
        metric: http_request_duration_seconds_count{
          job="payment-api"
        }
      grouping:
        - route
  alerting:
    severities:
      fastBurn: "page"
      mediumBurn: "ticket"

---
apiVersion: pyrra.dev/v1alpha1
kind: ServiceLevelObjective
metadata:
  name: payment-db-health
  namespace: monitoring
  labels:
    pyrra.dev/team: payments
    pyrra.dev/service: payment-api
spec:
  target: "99.5"
  window: 1w
  description: "DB 连接池健康度（使用率 < 90%）"
  indicator:
    bool_gauge:
      metric: (db_connections_active{job="payment-api"}
               / db_connections_max{job="payment-api"}) < 0.9

💡 grouping 在多路由场景的威力 上面的 payment-availability 和 payment-latency 都使用了 grouping: [route]。如果你的支付 API 有 /pay、/refund、/query 三个路由，Pyrra 会自动为每个路由生成独立的 SLO——3 个路由 × 2 个 SLI = 6 个可独立查看的 SLO，而配置文件只有 2 个 SLO 定义。

标签传播机制

以 pyrra.dev/ 为前缀的 metadata labels 会自动传播到生成的 Prometheus 规则中，前缀被去除：

yaml

metadata:
  labels:
    pyrra.dev/team: payments       # → Prometheus label: team="payments"
    pyrra.dev/service: payment-api # → Prometheus label: service="payment-api"
    pyrra.dev/env: production      # → Prometheus label: env="production"

这意味着你在 Alertmanager 里可以直接按 team、service、env 路由告警，不需要额外配置。

9 Web UI 使用指南

Web UI 是 Pyrra 相对于 Sloth 的最大优势。访问 http://<pyrra-api>:9099 打开。

SLO 列表页

功能	说明
搜索	按名称或标签搜索 SLO
排序	默认按剩余 error budget 升序——最差的 SLO 排在最前面
标签筛选	点击任意标签值，快速筛选包含该标签的所有 SLO
列控制	可显示/隐藏列：目标、可用性、错误预算、窗口、状态
颜色编码	绿色=健康，黄色=预警，红色=预算耗尽

SLO 详情页

点击任意 SLO 进入详情页，展示三大核心数字和多个图表：

三大核心数字：Objective（SLO 目标）、Availability（当前可用性）、Error Budget（剩余错误预算百分比）。这三个数字一眼看出 SLO 健康状况。
错误预算趋势图：展示错误预算随时间的变化曲线。支持绝对/相对刻度切换、自定义时间范围。曲线下降说明预算在消耗，下降到 0 意味着 SLO 破裂。
RED 指标图：Request（请求量）、Errors（错误量）、Duration（延迟）。帮你理解 SLO 变化的根本原因——是请求量暴增？错误突增？还是延迟恶化？
Multi Burn Rate Alerts 表：展示 4 级告警的当前状态——哪一级正在触发，燃烧率是多少，窗口匹配情况。帮你快速判断是否需要介入。

在线 Demo

不想部署也想体验？Pyrra 提供了在线 Demo：

Web UI：demo.pyrra.dev
Grafana Dashboard：demo.pyrra.dev/grafana

10 Grafana 集成

方式一：Generic Rules（自动生成 Dashboard）

启动 API 时加上 --generic-rules 参数，Pyrra 会生成兼容 Grafana 的通用规则，自动创建 Grafana Dashboard：

shell

pyrra api \
  --prometheus-url=http://prometheus:9090 \
  --grafana-external-url=http://grafana:3000 \
  --grafana-external-datasource-id=cemv8t0tc1hq8b \
  --generic-rules

方式二：导入官方 Dashboard

下载 Dashboard JSON：从 Pyrra GitHub 的 examples/grafana 目录下载 detail.json
Grafana → Dashboards → Import：上传 JSON 文件，选择 Prometheus 数据源
使用 Variables 筛选：Dashboard 内置 slo、team、service 变量，可在顶部下拉切换

关键 PromQL 查询

promql

# 错误预算剩余比例
1 - http_requests:burnrate2d

# 当前可用性
1 - (
  sum(http_requests:increase2w{type="error"})
  / sum(http_requests:increase2w{type="total"})
)

# 实时燃烧率（5 分钟窗口）
http_requests:burnrate3m

11 高级用法

Thanos / Mimir 支持

Pyrra 原生支持 Thanos 和 Mimir：

shell

# Thanos：禁用部分响应，下采样到 5m 和 1h
pyrra api \
  --prometheus-url=http://thanos-query:9090 \
  --prometheus-external-url=http://thanos.example.com

# Mimir：多租户查询
pyrra api \
  --prometheus-url=http://mimir:9009/prometheus \
  --mimir-tenant-ids=tenant1,tenant2

在 SLO 配置中可以指定 Thanos 的部分响应策略：

yaml

spec:
  target: "99.9"
  window: 2w
  # Thanos 部分响应策略：abort（中断）或 warn（告警）
  partial_response_strategy: abort
  indicator:
    ratio: { ... }

RuleOutput：自定义规则标签

如果你需要为生成的 PrometheusRule 添加自定义标签（比如用于 ArgoCD 同步筛选）：

yaml

spec:
  target: "99.9"
  window: 2w
  indicator:
    ratio: { ... }
  ruleOutput:
    # Short rules 的标签
    shortRulesLabels:
      argocd.argoproj.io/sync-wave: "1"
    # Long rules 的标签
    longRulesLabels:
      argocd.argoproj.io/sync-wave: "2"
    # 将 description 作为 PrometheusRule 的标签
    enableDescriptionAsLabel: true

性能优先模式

yaml

spec:
  target: "99.9"
  window: 2w
  # 用更快但不精确的查询（适合高基数指标）
  performanceOverAccuracy: true
  indicator:
    ratio: { ... }

开启后，Pyrra 会使用 rate() 而非 increase() 来计算窗口增长——前者更快但可能在窗口边界丢数据，后者精确但计算量大。高基数指标（如 per-pod 请求量）建议开启。

ConfigMap 模式（无 Prometheus Operator）

如果集群中没有 Prometheus Operator，Pyrra 可以把规则写入 ConfigMap：

shell

# 启动 Operator 时启用 ConfigMap 模式
pyrra kubernetes --config-map-mode=true

12 避坑指南

⚠️ 坑1：target 用了数字而不是字符串 CRD 中 target 必须是字符串："99.9" 而不是 99.9。如果不加引号，kubectl 可能自动转成字符串，也可能报 CRD 校验错误。
解法：所有 target 值都加引号，养成习惯。

⚠️ 坑2：latency 类型的 success 缺少 le 标签 latency 类型的 success.metric 必须包含 le 标签匹配器（如 le="0.5"），否则校验失败。这是 Pyrra 强制的——它通过 le 判断你使用的 histogram bucket。
解法：success 用 _bucket{le="阈值"}，total 用 _count。

⚠️ 坑3：grouping 导致规则爆炸 如果 grouping 的标签基数很高（如 instance、pod），每个标签值都会生成独立的 recording rules。100 个 pod = 100 套规则 = 800 条 recording rules，可能拖慢 Prometheus。
解法：grouping 只用于有意义的业务标签（如 route、method），不要用于基础设施标签（如 pod、instance）。

⚠️ 坑4：Prometheus Operator 版本不兼容 Pyrra 生成的 PrometheusRule 对象需要 Prometheus Operator v0.40+ 才能正确识别。旧版 Operator 可能忽略 Pyrra 生成的规则。
解法：升级 Prometheus Operator 到最新版，或使用 ConfigMap 模式。

⚠️ 坑5：Web UI 查询超时 SLO 数量多时，Web UI 的列表页会同时查询所有 SLO 的错误预算，可能超时。
解法：Pyrra 内置了查询缓存（ristretto），但首次加载可能慢。确保 Prometheus 的查询超时设置足够（建议 60s+），或减少同时展示的 SLO 数量。

⚠️ 坑6：bool_gauge 的查询返回非 0/1 值 bool_gauge 类型要求指标返回 0 或 1。如果你的查询返回其他值（如百分比 0-100），Pyrra 会按 0 处理。
解法：确保 bool_gauge 的 metric 查询返回布尔值。如 (db_connections_active / db_connections_max) < 0.9 返回 1（true）或 0（false）。

13 Pyrra vs Sloth：深度对比

前面零散提到了差异，这里做一个系统性的对比，帮你做选型决策。

维度	Pyrra	Sloth
定位	SLO 运营平台（生成 + UI + 管理）	SLO 规则生成器（只生成）
运行模式	长运行服务（Operator + API）	CLI 工具（一次性生成）
配置格式	Kubernetes CRD	YAML 文件
SLI 类型	4 种：ratio / latency / latencyNative / bool_gauge	3 种：events / raw / plugins
延迟 SLI	原生支持（latency 类型，语义清晰）	需用 events 类型手动算 _count - _bucket
分组（grouping）	✅ 一条配置展开多个 SLO	❌ 每个分组需单独配置
告警级别	4 级（critical / warning / slow / long）	2 级（page / ticket）
缺失指标告警	✅ 自动生成	❌ 需手动配置
Web UI	✅ SLO 列表 + 详情 + RED 指标	❌ 无
Grafana Dashboard	✅ 自动生成	需手动导入
非 K8s 场景	✅ filesystem 模式	✅ CLI 模式
OpenSLO 支持	❌ 不支持	✅ 支持
SLI 插件	❌ 无插件机制	✅ 社区插件库
CI/CD 集成	通过 GitOps（ArgoCD/Flux）同步 CRD	CI 中运行 CLI 生成规则
维护方	Grafana Labs / Polar Signals	slok（个人维护）

选型建议

选 Pyrra 如果你：

✅ 在 Kubernetes 上运行
✅ 需要 Web UI 查看 SLO 状态
✅ 需要为多个路由/端点分别管理 SLO（grouping）
✅ 需要延迟 SLO 且不想手写 histogram 计算
✅ 团队需要可视化运营而非纯命令行

选 Sloth 如果你：

✅ 不在 Kubernetes 上（裸机 / VM）
✅ 只需要生成规则，不需要 UI
✅ 需要 OpenSLO 格式支持
✅ 需要用 SLI 插件简化配置
✅ 团队习惯 GitOps + CLI 工作流

🔑 可以同时用！ Pyrra 和 Sloth 不互斥。一些团队的做法是：用 Sloth 在 CI 中生成基础规则（可用性、错误率），用 Pyrra 在 K8s 中管理需要 grouping 和 UI 运营的复杂 SLO（延迟、多路由）。两者生成的规则都是标准 Prometheus 规则，可以在同一个 Prometheus 中共存。

结语：选对工具，把精力留给决策

回顾整个 SLO 工具系列：

SLO 落地实战：讲的是"什么是 SLO、为什么需要、怎么从 0 到 1 搭建"——体系全貌
Sloth 实战指南：讲的是"用 CLI 工具把 YAML 转成 Prometheus 规则"——轻量自动化
Pyrra 实战指南（本文）：讲的是"用 K8s 原生平台管理 SLO 全生命周期"——完整运营

三篇文章的共同主题是：把重复劳动交给工具，把精力留给真正需要人的判断。

Pyrra 的核心价值不只是自动生成规则——更重要的是它让 SLO 变得可运营。Web UI 让你一眼看到哪个服务的错误预算快耗尽了；grouping 让你不用为每个路由写一套配置；四级告警让你精细控制什么级别的问题需要什么响应。这些能力把 SLO 从"写在文档里的目标"变成了"每天可观测、可管理的工程实践"。

SLO 的终极目标不是生成完美的 Prometheus 规则，而是让团队形成"用数据做可靠性决策"的习惯。Pyrra 提供了工具，但习惯的养成需要人。

SRE 实战手册 · 工具实战系列Pyrra 项目地址: github.com/pyrra-dev/pyrra | 在线 Demo: demo.pyrra.dev | 官方文档: github.com/pyrra-dev/pyrra#readme

Pyrra 实战指南：Kubernetes 原生的 SLO 监控工具 原创 ​

1 Pyrra 的定位：不只是规则生成器 ​

2 架构概览：三组件设计 ​

两种运行模式 ​

3 安装部署 ​

方式一：Kubernetes + Helm（推荐） ​

方式二：Kubernetes + 原生 YAML ​

方式三：Docker / 文件系统模式 ​

4 CRD 配置详解 ​

基础示例：HTTP API 可用性 ​

Spec 字段详解 ​

5 四种 SLI 类型 ​

类型一：ratio（错误率，最常用） ​

类型二：latency（延迟，直方图） ​

类型三：latencyNative（原生直方图延迟） ​

类型四：bool_gauge（布尔指标） ​

grouping：一条配置覆盖多个 SLO ​

6 理解 Pyrra 生成的规则 ​

Recording Rules ​

Alert Rules：四级燃烧率告警 ​

Short / Long 规则分离 ​

缺失指标告警 ​

7 告警配置 ​

自定义告警名称和 Severity ​

禁用告警 ​

Alertmanager 路由 ​

8 实战：多服务多 SLI 配置 ​

支付服务：可用性 + 延迟 + DB 健康 ​

标签传播机制 ​

9 Web UI 使用指南 ​

SLO 列表页 ​

SLO 详情页 ​

在线 Demo ​

10 Grafana 集成 ​

方式一：Generic Rules（自动生成 Dashboard） ​

方式二：导入官方 Dashboard ​

关键 PromQL 查询 ​

11 高级用法 ​

Thanos / Mimir 支持 ​

RuleOutput：自定义规则标签 ​

性能优先模式 ​

ConfigMap 模式（无 Prometheus Operator） ​

12 避坑指南 ​

13 Pyrra vs Sloth：深度对比 ​

选型建议 ​

结语：选对工具，把精力留给决策 ​

Pyrra 实战指南：Kubernetes 原生的 SLO 监控工具原创

1 Pyrra 的定位：不只是规则生成器

2 架构概览：三组件设计

两种运行模式

3 安装部署

方式一：Kubernetes + Helm（推荐）

方式二：Kubernetes + 原生 YAML

方式三：Docker / 文件系统模式

4 CRD 配置详解

基础示例：HTTP API 可用性

Spec 字段详解

5 四种 SLI 类型

类型一：ratio（错误率，最常用）

类型二：latency（延迟，直方图）

类型三：latencyNative（原生直方图延迟）

类型四：bool_gauge（布尔指标）

grouping：一条配置覆盖多个 SLO

6 理解 Pyrra 生成的规则

Recording Rules

Alert Rules：四级燃烧率告警

Short / Long 规则分离

缺失指标告警

7 告警配置

自定义告警名称和 Severity

禁用告警

Alertmanager 路由

8 实战：多服务多 SLI 配置

支付服务：可用性 + 延迟 + DB 健康

标签传播机制

9 Web UI 使用指南

SLO 列表页

SLO 详情页

在线 Demo

10 Grafana 集成

方式一：Generic Rules（自动生成 Dashboard）

方式二：导入官方 Dashboard

关键 PromQL 查询

11 高级用法

Thanos / Mimir 支持

RuleOutput：自定义规则标签

性能优先模式

ConfigMap 模式（无 Prometheus Operator）

12 避坑指南

13 Pyrra vs Sloth：深度对比

选型建议

结语：选对工具，把精力留给决策